Купить ГОСТ Р 55687-2013 — бумажный документ с голограммой и синими печатями. подробнее
Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"
Наши цены ниже, чем в других местах, потому что мы работаем напрямую с поставщиками документов.
Распространяется на контрольный радиоприемник системы цифрового наземного узкополосного мультимедийного вещания РАВИС в ОВЧ диапазоне частот, предназначенный для приема и измерения основных параметров сигнала РАВИС.
1 Область применения
2 Нормативные ссылки
3 Термины, определения, обозначения и сокращения
4 Основные параметры
5 Технические требования
Приложение А (обязательное) TAG-пакеты данных, управления и мониторинга
Библиография
Дата введения | 01.09.2014 |
---|---|
Добавлен в базу | 01.10.2014 |
Актуализация | 01.01.2021 |
31.10.2013 | Утвержден | Федеральное агентство по техническому регулированию и метрологии | 1330-ст |
---|---|---|---|
Разработан | ООО НПФ САД-КОМ | ||
Издан | Стандартинформ | 2014 г. |
Чтобы бесплатно скачать этот документ в формате PDF, поддержите наш сайт и нажмите кнопку:
ГОСТР 55688 — 2013
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ
НАЦИОНАЛЬНЫЙ
СТАНДАРТ
РОССИЙСКОЙ
ФЕДЕРАЦИИ
Издание официальное
Москва
Стандартинформ
2014
1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Научно-производственная фирма «САД-КОМ» (ООО «НПФ «САД-КОМ»)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 480 «Связь»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 31 октября 2013 г. № 1331-ст
4 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок - в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru).
© Стандартинформ, 2014
Настоящий стандарт не может быть воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии
2) от внешнего источника постоянного тока с номинальным напряжением от 12 до 60 В. В этом случае требования к электропитанию должны соответствовать приложению 3 Правил [3];
3) от аккумуляторов и батарей. В этом случае требования к электропитанию устанавливаются в соответствии с разделом X Правил [3].
6.4.2 Для оборудования формирователя контента, устанавливаемого внутрь компьютера или иного электронно-цифрового устройства, требования к электропитанию оборудования определяются устройством, в которое оно устанавливается.
6.5 Требования устойчивости к климатическим и механическим воздействиям
6.5.1 Оборудование формирователя контента должно сохранять работоспособность при климатических и механических воздействиях, параметры которых приведены в таблице 2 (в соответствии с ГОСТ 22261-94 для средств измерений группы 2)
Таблица 2 - Параметры климатических и механических воздействий | ||||||||||||||
|
8
Приложение А (обязательное)
ТК РАВИС является универсальным протоколом хранения и передачи информации.
С помощью ТК РАВИС можно мультиплексировать до (232 - 1) независимых потоков данных.
Поток ТК РАВИС состоит из страниц, которые могут содержать:
• пакеты данных элементарных потоков;
• пакеты описаний элементарных потоков;
• пакеты описаний групп элементарных потоков.
Структура пакетов описаний элементарных потоков приводится в разделе А.2.3. Структура пакетов описаний групп элементарных потоков приводится в разделе А.2.4.
Пакеты описаний элементарных потоков и пакеты описаний групп элементарных потоков называются системными пакетами.
При использовании ТК РАВИС в системе РАВИС группа элементарных потоков представляет собой сервис РАВИС.
Описания элементарных потоков и описания групп элементарных потоков при потоковом вещании должны периодически вставляться в поток ТК РАВИС. При файловом хранении описания могут вставляться один раз в начале файла.
Данные типы страниц используются для размещения пакетов данных одного элементарного потока или системных пакетов соответственно.
Заголовки страниц данных типов отличаются только значением флага «page_type»: для страницы с данными одного элементарного потока это биты 00Ь, для страницы с системными пакетами - 01Ь.
Заголовок страницы состоит из:
• флагов заголовка;
• данных заголовка.
Структура флагов заголовка страницы представлена в таблице А.1. Описание флагов заголовка представлено в таблице А.2.
Структура данных заголовка зависит от значений флагов. В таблице А.4 представлена побайтовая структура страницы с возможными (в зависимости от флагов) размерами полей данных заголовка.
Таблица А.1 - Структура флагов заголовка страницы с данными одного элементарного потока, заголовка страницы с системными пакетами
бит 0 | бит 1 |
бит 2 | бит 3 |
бит 4 | бит 5 |
бит 6 | бит 7 | ||||
байт 0 |
page type |
has size |
has es id |
has ts | |||
байт 1 |
has pn | has pkt sz |
has pkt ts |
has 4cc |
more | |||
байт 2 |
same sz |
packet part |
bos eos nos |
more | |||
байт 3 |
has crc |
has stuffing | | |
_1 |
more |
9
Таблица А.2 - Описание флагов заголовка страницы с данными одного элементарного потока и заголовка страницы с системными пакетами
Флаг |
Длина (бит) |
Описание |
page_type |
2 |
00b-для страницы сданными одного элементарного потока; 01 b - для страницы с системными пакетами. |
has_size |
2 |
Длина поля size, содержащего размер данных, размещенных после заголовка: • 00b - 1 байт; • 01Ь-2байта; • 10Ь-4байта. |
has_es_id |
2 |
Длина поля es_id, содержащего идентификатор элементарного потока: • 00Ь - нет; • 01 b - 1 байт; • 10Ь-2байта; • 11Ь-4байта. |
has_ts |
2 |
Длина поля timestamp, определяющего временную метку: • 00Ь - нет; • 01Ь-2байта; • 10Ь-4байта; • 11Ь-8 байтов. |
has_pn |
3 |
Длина поля page_number, определяющего номер страницы: • 000b - нет; • 001 b - 1 байт; • 010Ь-2 байта; • 011Ь-4 байта; • ЮОЬ - 8 байтов. |
has_pkt_sz |
2 |
Длина поля packet_sz, определяющего размер пакета11: • 00Ь - нет; • 01 b — 1 байт; • 10Ь-2байта; • 11Ь-4байта. |
has_pkt_ts |
1 |
Флаг размещения перед каждым пакетом его временной метки. Размер поля этих временных меток определяется флагом has_ts. В случае если has pkt ts = 1, временная метка для всей страницы не вставляется. |
has 4cc |
1 |
Флаг присутствия поля FOURCC. Если флаг не присутствует - значение 0. |
same_sz |
1 |
Признак того, что пакеты внутри страницы имеют одинаковый размер. Если флаг не присутствует - значение 0 (пакеты разных размеров). |
packet_part |
4 |
Определяет, целые ли пакеты находятся в начале и конце полезной нагрузки страницы. Если не целые, то определяет количество байт, выделенных для определения размеров нецелых частей (см. таблицу А.З). Если поле не присутствует - значение 0000b. |
bos eos nos |
2 |
Состояние потока: • 01 b - начало потока; • 00Ь - нормальное состояние потока (по умолчанию); • 11Ь - конец потока; • 10Ь - зарезервировано. |
has_crc |
1 |
Флаг присутствия поля CRC (CRC подсчитывается для полезной нагрузки страницы). Если поле не присутствует-значение 0 (поле CRC отсутствует). |
has_stuffing |
2 |
Длина поля stuffing, определяющего длину заполнения: • 00Ь - нет (по умолчанию); • 01 b — 1 байт; • 10Ь-2байта; • 11Ь-4байта. |
more |
1 |
Флаг указывает присутствие следующего байта флагов заголовка: • 1 b - следующий байт представляет флаги заголовка; • 0Ь - после данного бита начинаются данные заголовка. |
^ Поле packet_sz размещается в зависимости от значения флага same_sz: если значение 1, то packet_sz размещается один раз перед данными первого пакета, если 0 - то перед данными каждого пакета.
10
Таблица А.З-Значения поля «packet_part» | ||||||||||||||||||||||||||||||||||
|
Таблица А.4- Побайтовая структура страницы сданными одного элементарного потока и страницы с системными пакетами_ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Для всех флагов в байтах, следующих в таблице А.1 за байтом, где флаг «тоге» равен 0Ь, принимаются значения по умолчанию. Для последнего байта флагов заголовка и подзаголовка флаг «тоге» должен быть равен 0Ь.
Поле «size» должно определять размер полезной нагрузки страницы, т.е. данных страницы, следующих после заголовка. Размер поля «size» определяется флагом «has_size» заголовка страницы.
Поле «es_id» присутствует только в странице с пакетами одного элементарного потока («page_type» = 00b) и должно содержать идентификатор элементарного потока. Размер поля определяется флагом «has_es_id». В случае страницы, содержащей системные пакеты («page_type»
11
= 10b ), флаг «has_es_id» определяет размер поля «es_id» для пакетов описания элементарных потоков (см. раздел А.2.3).
Поле «page_number» должно содержать номер страницы в хронологическом порядке. Номер страницы может служить для контроля порядка обработки принятых от удаленной стороны страниц. Размер поля «page_number» определяется флагом «has_page_num». Максимально возможное значение номера страницы, после которого номер следующей страницы становится равен 0, должно быть заранее известно принимающей стороне.
Поле «4сс» может присутствовать только в странице с пакетами одного элементарного потока («page_type» = 00b) и должно содержать значение FOURCC для пакетов данного элементарного потока в данной странице. Присутствие данного поля определяется флагом «has_4cc». Для страницы, содержащей системные пакеты («page_type» = 10b), флаг «has_4cc» должен быть установлен в 0Ь.
Поле «CRC» должно содержать значение CRC-32, вычисленное для полезной нагрузки страницы (алгоритм расчета приведен в приложении Г). Присутствие поля «CRC» определяется флагом «has_crc».
Поля «begin_pkt_part» и «end_packet_part», если присутствуют, должны содержать размер частичных данных в начале и в конце полезной нагрузки страницы соответственно. Присутствие и размер данных полей определяется флагом «packet_part» в соответствии с таблицей А.З. Частичные данные в начале полезной нагрузки считаются принадлежащими к предыдущей в хронологическом порядке странице, а в текущей странице эта часть данных должна быть проигнорирована.
Поле «stuffing», если присутствует, должно содержать размер заполнения в конце полезной нагрузки, которое должно быть проигнорировано при дальнейшей обработке содержимого страницы. Длина поля «stuffing» определяется флагом «has_stuffing» (см. таблицу А.2). Присутствие поля «stuffing» имеет смысл в страницах фиксированного размера.
Данные страницы составляют один или несколько пакетов данных элементарного потока или системных пакетов. Первым пакетом текущей страницы считается пакет, следующий сразу за частичными данными в начале полезной нагрузки, если они есть.
Если пакетов в странице несколько, то могут быть указаны их размеры. Для указания длины поля с размером пакетов («packet_size») используется флаг «has_pkt_sz».
Если «has_pkt_sz» не равно 00Ь, то в зависимости от значения флага «same_sz» поле «packet_size» размещается (см. таблицу А.4):
• один раз и относится ко всем пакетам («same_sz» = 1b);
• перед каждым пакетом («same_sz» = 0Ь).
Если «same_sz» = 1b и «has_pkt_sz» = 00b, то страница должна быть проигнорирована.
Если «has_pkt_ts» = 1b, то временная метка указывается для каждого пакета отдельно, ее размер определяется полем «has_ts», временная метка для страницы в целом в этом случае не указывается (см. таблицу А.4).
А.2.2 Страница с пакетами данных разных элементарных потоков и системными пакетами
Данный тип страницы используется для размещения пакетов данных разных элементарных потоков, на этой же странице могут быть размещены системные пакеты.
Заголовок страницы состоит из:
• флагов заголовка;
• данных заголовка.
Пакеты на странице размещаются в порядке поступления, предварительной сортировки не происходит. Каждому пакету, размещенному на странице, должен соответствовать подзаголовок. Подзаголовок может соответствовать нескольким размещенным друг за другом пакетам, совокупность таких пакетов называется подстраницей. Подзаголовок (или заголовок подстраницы) состоит из:
• флагов подзаголовка;
• данных подзаголовка.
Структура флагов заголовка страницы представлена в таблице А.5.
Структура флагов заголовка подстраницы представлена в таблице А.6.
Описание флагов заголовка страницы и заголовка подстраницы представлено в таблице А.7.
Структура данных заголовка зависит от значений флагов. В таблице А.8 представлена побайтовая структура страницы с возможными, в зависимости от флагов, размерами полей данных заголовка и подзаголовка.
Таблица А.5 - Структура флагов заголовка страницы с пакетами данных разных элементарных потоков и системными пакетами | |||||||||||||||
|
Таблица А.6 - Структура флагов заголовка подстраницы страницы с пакетами данных разных элементарных потоков и страницы с системными пакетами | ||||||||||||||||||
|
Таблица А.7 - Описание полей заголовка и подзаголовка страницы с пакетами данных разных элементарных потоков и страницы с системными пакетами_ | ||||||||||||||||||||||||||||||||||||||||||
|
13
Окончание таблицы А. 7 | |||||||||||||||
|
Таблица А.8 - Побайтовая структура страницы с данными одного элементарного потока и страницы с системными пакетами _ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
ГОСТ P 55688 —2013
Данная страница определяется по значению поля «page_type», которое должно быть установлено в значение 10Ь.
Для всех флагов в байтах, следующих в таблицах А. 5 и А.6 за байтом, где флаг «тоге» равен 0Ь, принимаются значения по умолчанию. Для последнего байта флагов заголовка и подзаголовка флаг «тоге» должен быть равен 0Ь.
А.2.2.1 Описание полей заголовка страницы
Поле «size» должно определять размер полезной нагрузки страницы, т.е. данных страницы, следующих после заголовка. Размер поля «size» определяется флагом «has_size» заголовка страницы.
Поле «page_number» должно содержать номер страницы в хронологическом порядке. Номер страницы может служить для контроля порядка обработки принятых от удаленной стороны страниц. Размер поля «page_number» определяется флагом «has_page_num». Максимально возможное значение номера страницы, после которого номер следующей страницы становится равен 0, должно быть заранее известно принимающей стороне.
Поля «begin_pkt_part» и «end_packet_part», если присутствуют, должны содержать размер частичных данных в начале и в конце полезной нагрузки страницы соответственно. Присутствие и размер данных полей определяется флагом «packet_part» в соответствии с таблицей А.З. Частичные данные в начале полезной нагрузки считаются принадлежащими к предыдущей в хронологическом порядке странице, а в текущей странице эта часть данных должна быть проигнорирована.
Поле «stuffing»,если присутствует, должно содержать размер заполнения в конце полезной нагрузки, которое должно быть проигнорировано при дальнейшей обработке содержимого страницы. Длина поля «stuffing» определяется флагом «has_stuffing» (см. таблицу А.7). Поле «stuffing» имеет смысл в страницах фиксированного размера.
Поле «CRC» должно содержать значение CRC-32, вычисленное для полезной нагрузки страницы (алгоритм вычисления CRC-32 приведен в приложении Г). Присутствие поля «CRC» определяется флагом «has_crc».
А.2.2.2 Описание полей заголовка подстраницы
Поле «es_id» присутствует только в подстранице с пакетами данных элементарного потока. Оно должно содержать идентификатор элементарного потока. Размер поля определяется флагом «has_es_id». В случае, когда подстраница содержит системные пакеты, флаг «has_es_id» определяет размер поля «es_id» для соответствующих системных пакетов (см. раздел А.2.3, А.2.4).
Поле «4сс» присутствует только в подстранице с пакетами данных элементарного потока. Оно должно содержать значение FOURCC для пакетов данного элементарного потока в данной подстранице. Присутствие данного поля определяется флагом «has_4cc». В случае, когда подстраница содержит системные пакеты, флаг «has_4cc» должен быть установлен в 0.
Данные подстраницы составляет один или несколько пакетов данных элементарного потока или системных пакетов.
Если пакетов в странице несколько, то могут быть указаны их размеры. Для указания длины поля с размером пакетов («packet_size») используется флаг «has_pkt_sz».
Если «has_pkt_sz» не равно 00Ь, то в зависимости от значения флага «same_sz» поле «packet_size» размещается (см. таблицу А.8):
• один раз и относится ко всем пакетам («same_sz» = 1b);
• перед каждым пакетом (same_sz» = Ob).
Если «same_sz» = 1b и «has_pkt_sz» = 00b, то вся страница должна быть проигнорирована.
Если «h_pkt_ts» = 1b, то временная метка указывается для каждого пакета отдельно, ее размер определяется полем «has_ts», временная метка для подстраницы в целом в этом случае не указывается (см. таблицу А.8).
А.2.3 Пакеты описания элементарных потоков
Данный тип пакетов относится к системным пакетам и предназначен для хранения описания элементарного потока.
Пакет может располагаться на странице с системными пакетами («page_type»=’01 Ь’) либо на подстранице (с установленным флагом «system») страницы «page_type» = 10b.
Пакет состоит из заголовка и опционально из расширенных данных пакета.
Заголовок пакета состоит из:
• флагов заголовка;
• данных заголовка.
Структура флагов заголовка пакета представлена в таблице А.9. Описание флагов заголовка представлено в таблице А.10.
15
Структура данных заголовка зависит от значений флагов. В таблице А.11 представлена побайтовая структура пакета с возможными (в зависимости от флагов) размерами полей данных заголовка.
Таблица А.9 - Структура флагов заголовка пакета, содержащего описание элементарного потока | ||||||||||||||||||||||||
|
Таблица А.10-Описание флагов заголовка пакета, содержащего описание элементарного потока | ||||||||||||||||||||||||||||||
|
16
Таблица А.11 - Побайтовая структура пакета с описанием элементарного потока | ||||||||||||||||||||||||
|
Под родителем пакета далее будет пониматься страница с «page_type» = 01b или подстраница страницы с «page_type» = 10b, содержащая данный пакет.
В первом бите первого байта заголовка системных пакетов (пакетов описания элементарных потоков и пакетов описания групп элементарных потоков) находится флаг «sys_std», определяющий принадлежность данного пакета к стандартным системным пакетам.
Если флаг «sys_std» = 1b, то данный пакет является одним из стандартных системных пакетов, тогда тип этого пакета определяется флагом «std_sys_type» (2-й и 3-й биты первого байта заголовка, см. таблицу А.10). Для пакета описания элементарного потока значение флага «std_sys_type» должно быть равно 00Ь.
Если флаг «sys_std» = Ob, то такой пакет должен быть проигнорирован (зарезервировано для возможных дальнейших расширений протокола).
Поле «es_id» должно определять идентификатор описываемого в данном пакете элементарного потока. Размер поля «es_id» определяется флагом «has_es_id» родителя пакета.
Присутствие поля «FOURCC» определяется флагом «has_4cc» заголовка пакета, если он равен 1Ь, то поле присутствует и должно содержать значение FOURCC для описываемого данным пакетом элементарного потока.
Поле «ts_a_f», если присутствует, должно определять формат абсолютной временной метки, которая находится в поле «timestamp» родителя пакета, относящемся к данному пакету. Присутствие поля «ts_a_f» определяется флагом «h_ts_a_f». Возможные значения поля «ts_a_f» указаны в таблице А.12. Если поле «timestamp» родителя пакета, относящееся к данному пакету, присутствует (оно содержит абсолютную временную метку), a «h_ts_a_f» = Ob, то формат абсолютной временной метки определяется исходя из размера поля «timestamp» родителя пакета в соответствии с таблицей А.13.
Поле «ts_es_f», если присутствует, должно определять формат временных меток описываемого элементарного потока. Присутствие поля «ts_es_f» определяется флагом «h_ts_es_f» и если он равен 1Ь, то поле присутствует. Возможные значения поля «ts_es_f» указаны в таблице А.12. Если поле «ts_es_f» отсутствует, то формат временных меток для описываемого элементарного потока определяется исходя из размера поля «timestamp», относящегося к пакетам данных потока в соответствии с таблицей А.13.
Поле «ts_es», если присутствует, должно определять временную метку описываемого элементарного потока, которой соответствует абсолютная временная метка для данного пакета описания элементарного потока. Формат временной метки, помещаемой в поле «ts_es» должен соответствовать формату временных меток описываемого потока. Присутствие поля «ts_es» определятся флагом «h_ts_es», если «h_ts_es» = 1b, то поле присутствует.
Если размер пакета, указанный в родителе пакета, больше, чем заголовок пакета, то остальные данные - расширенные данные пакета. Их формат определяется флагами «compress» и «dformat». Флаг «compress» определяет способ сжатия расширенных данных (см. описание флага «compress» в таблице А.10). Флаг «dformat» определяет формат, в котором представлены расширенные данные (см. описание флага «dformat» в таблице А.10).
Флаг «crypted» указывает, что данные описываемого элементарного потока зашифрованы. Данные, необходимые для дешифрации, должны находиться в расширенных данных потока (см. приложение Б).
17
ГОСТ P 55688 —2013
1 Область применения.....................................................................................................1
2 Нормативные ссылки..........................................................................................................................1
3 Термины, определения, обозначения и сокращения.......................................................................2
4 Общее описание..................................................................................................................................3
5 Основные параметры.........................................................................................................................5
6 Технические требования....................................................................................................................7
Приложение А (обязательное) Описание ТК РАВНО..............................................................................9
Приложение Б (информационное) Примеры расширенных данных системных пакетов ТК
РАВНО........................................................................................................................................................21
Приложение В (обязательное) Правила формирования TAG-пакета для входа
формирователя контента.........................................................................................................................23
Приложение Г (обязательное) Вычисление циклического избыточного кода.....................................26
Библиография...........................................................................................................................................27
Таблица А 12- Возможные значения формата временной метки | ||||||||||
|
Таблица А.13 - Форматы временной метки по умолчанию в зависимости от размера поля временной метки | ||||||||
|
А.2.4 Пакеты описания групп элементарных потоков
Данный тип пакетов относится к системным пакетам и предназначен для хранения описания одной или нескольких групп элементарных потоков.
Пакет может располагаться на странице с системными пакетами («page_type» = 01b) либо на подстранице (с установленным флагом «system») страницы «page_type» = 10b.
Пакет состоит из заголовка, основных данных пакета и опционально из расширенных данных пакета.
Заголовок пакета состоит из флагов.
Структура флагов заголовка пакета представлена в таблице А.14. Описание флагов заголовка представлено в таблице А.15.
Структура данных заголовка зависит от значений флагов. В таблице А.16 представлена побайтовая структура пакета.
Таблица А.14- Структура фтагов заголовка пакета с описанием группы элементарных потоков | ||||||||||||||||||
|
18
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
АУДИОВИЗУАЛЬНАЯ ИНФОРМАЦИОННАЯ СИСТЕМА РЕАЛЬНОГО ВРЕМЕНИ (РАВИС)
Формирователь контента.
Структура и протоколы передачи данных
Realtime audiovisual information system (RAVIS).
Content composer. Structure and data transmission protocols
Дата введения —2014—09—01
Настоящий стандарт распространяется на формирователь контента системы цифрового наземного узкополосного мультимедийного вещания РАВИС в ОВЧ диапазоне частот, предназначенный для формирования мультиплекса РАВИС, передаваемого на цифровой модулятор РАВИС для вещания.
Система РАВИС позволяет осуществлять мультимедийное вещание для стационарного, переносного и мобильного приема. Система РАВИС обеспечивает передачу цифрового информационного потока в узкополосном канале с шириной полосы 100, 200 или 250 кГц.
Стандарт описывает общую структуру и протоколы передачи данных на входе и выходе формирователя контента.
Требования настоящего стандарта следует учитывать при разработке, изготовлении и эксплуатации формирователей контента РАВИС.
В настоящем стандарте использованы ссылки на следующие стандарты:
ГОСТ 12.1.030-81 Система стандартов безопасности труда. Электробезопасность. Защитное заземление,зануление
ГОСТ 12.2.007.0-75 Система стандартов безопасности труда. Изделия электротехнические. Общие требования безопасности
ГОСТ 15150-69 Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды
ГОСТ 22261-94 Средства измерений электрических и магнитных величин. Общие технические условия
ГОСТ Р 50829-95 Безопасность радиостанций, радиоэлектронной аппаратуры с использованием приемопередающей аппаратуры и их составных частей. Общие требования и методы испытаний
ГОСТ Р 54309-2011 Аудиовизуальная информационная система реального времени (РАВИС). Процессы формирования кадровой структуры, канального кодирования и модуляции для системы цифрового наземного узкополосного радиовещания в ОВЧ диапазоне. Технические условия
ГОСТ Р 54708-2011 Система цифрового звукового радиовещания DRM. Протокол распределения и коммутации (DCP)
ГОСТ Р МЭК 60065-2005 Аудио-, видео- и аналогичная электронная аппаратура. Требования безопасности
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по
Издание официальное
техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3.1 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1.1 байт: Набор из 8 битов.
3.1.2 кадр данных: Множество битов, формирующее блок входной информации для одного цикла канального кодирования.
3.1.3 мультиплекс: Совокупность логических каналов КОС, НСК, НКД.
3.1.4 полезная нагрузка: Данные страницы, подстраницы или пакета, следующие за заголовком.
3.1.5 протокол распределения и коммуникации (Distribution and Communication Protocol): Протокол связи транспортного уровня, обеспечивающий фрагментацию, адресацию и/или надежную передачу данных по каналам с ошибками с использованием кода Рида-Соломона для прямой коррекции ошибок путем введения избыточности.
3.1.6 сервис: Логически объединенный набор элементарных потоков.
3.1.7 строка ASCII: Текстовая строка, состоящая из символов, закодированных в соответствии с американской стандартной таблицей кодировки (American Standard Code for Information Interchange, ASCII).
3.1.8 студия: Комплекс аппаратного и программного обеспечения, формирующий на выходе один или несколько сервисов РАВИС.
3.1.9 схема мультиплекса: Перечисление входящих в мультиплекс сервисов (при необходимости с входящими в их состав элементарными потоками) и их места в мультиплексе с указанием источников данных для них.
3.1.10 транспортный поток MPEG-2 (MPEG-2 Transport Stream): Транспортный контейнер в соответствии со стандартом MPEG-2, часть 1 [1].
3.1.11 элементарный поток: Закодированный поток информации одного типа от одного источника данных.
3.1.12 Ethernet - Ethernet network - сеть Ethernet: Технология передачи данных в локальных компьютерных сетях, описанная стандартами IEEE группы 802.3.
3.1.13 TAG-значение (TAG Value): Нагрузка TAG-элемента.
3.1.14 TAG-название (TAG Name): Название поля в индивидуальном TAG-элементе, используемое для идентификации индивидуальной части информации.
3.1.15 TAG-пакет (TAG Packet): Набор TAG-элементов, переносящий связанный и отдельный блок данных.
3.1.16 TAG-элемент (TAG Item): DCP-элементный тип, объединяющий в единых логических данных имя, длину и значение данных.
3.1.17 UTF-8 текст: Текст, состоящий из символов, закодированных с помощью 8-битного Юникода (Unicode Transformation Format, UTF).
3.2 Обозначения
В настоящем стандарте применены следующие обозначения:
Nx - числовое значение «N», выраженное по основанию «х» (основание «х» должно быть десятичным числом, таким образом, 2Ai6 есть шестнадцатеричное представление десятичного числа 42);
Nb - числовое значение «N», выраженное по основанию «2».
2
ГОСТ P 55688 —2013
3.3 Сокращения
В настоящем стандарте применены следующие сокращения: 16-QAM - 16-позиционная модуляция QAM; | ||||
|
FOURCC - четырехбайтная последовательность, используемая для идентификации форматов | ||||||||||
|
4.1 Мультиплекс РАВИС
4.1.1 Все данные, передаваемые в одном радиоканале в системе РАВИС, логически представляют собой мультиплекс (см. рисунок 1). Мультиплекс состоит из логических каналов:
• КОС (обязательный);
• ИСК (опциональный);
• НКД (опциональный).
4.1.2 Каждый логический канал может содержать один или несколько сервисов.
4.1.3 Сервис представляет собой один или несколько логически объединенных элементарных потоков.
3
глыиплекс-
—Канал НКД-
^—Канал ИСК-
Канал КОС-
Саране 1
Сервис N
V
Рисунок 1 - Логическая структура мультиплекса РАВИС
4.1.4 Для кахщого элементарного потока в логических каналах должно передаваться его описание, за исключением случаев, когда формат передаваемых элементарных потоков известен заранее.
4.1.5 Описание элементарного потока должно включать параметры, необходимые для корректного декодирования и отображения информации элементарного потока.
4.1.6 Для каждого сервиса должно передаваться его описание, за исключением случаев, когда состав и описание сервисов известны заранее.
4.1.7 Описание сервиса должно включать перечисление элементарных потоков, из которых состоит сервис. Среди элементарных потоков сервиса может быть выбран один или несколько основных элементарных потоков, которые содержат основную информацию сервиса. В случае присутствия в сервисе нескольких элементарных потоков одного типа может быть указан приоритетный для отображения элементарный поток.
4.1.8 На вход формирователя контента должны поступать данные элементарных потоков и/или готовые сервисы. На выходе формирователь контента выдает мультиплекс в формате входа модулятора РАВИС.
4.2.1 Система формирования контента включает в себя:
• кодеры источников (кодеры аудио-, видео- и дополнительной информации);
• студии, выдающие готовые к дальнейшей упаковке и передаче сервисы;
• формирователь контента.
4.2.2 Формирователь контента должен включать:
• модуль упаковки данных логического канала (МУЛК), осуществляющий упаковку данных, предназначенных для передачи в логическом канале, в заданный формат, например ТК РАВИС (см. приложение А) или ТП MPEG-2;
• модуль упаковки данных логических каналов в КД РАВИС (МУКД);
• модуль формирования TAG-пакетов для входа модулятора (МФВМ).
ГОСТ P 55688 —2013
Рисунок 2 - Система формирования контента РАВИС |
4.3.1 Использование ТП MPEG-2 для упаковки данных логических каналов
ТП MPEG-2 может использоваться для упаковки данных логических каналов КОС, ИСК и НКД мультиплекса РАВИС. В этом случае программа ТП MPEG-2 представляет собой сервис РАВИС. В соответствующих КД биты 0 и 1 поля TYPE должны быть установлены в 11Ь, а бит 3 - в 0Ь (см. ГОСТ Р 54309-2011, раздел 5.2).
4.3.2 Использование ТК РАВИС для упаковки данных логических каналов
ТК РАВИС может использоваться для упаковки данных логических каналов КОС, ИСК и НКД мультиплекса РАВИС (см. приложение А). В этом случае группа элементарных потоков ТК РАВИС представляет собой сервис РАВИС. В соответствующих КД биты 0 и 1 поля TYPE должны быть установлены в 11Ь, а бит 3 - в 1 b (см. ГОСТ Р 54309-2011, раздел 5.2).
4.3.3 Использование других способов упаковки данных логических каналов
Для упаковки данных логических каналов КОС, НСК, НКД могут использоваться другие пакетные или потоковые протоколы. Формирование КД для пакетных и потоковых данных логических каналов описано в разделе 5.2 ГОСТ Р 54309-2011. Потоковые данные в логическом канале следует трактовать их как один сервис.
5.1 Для формирования мультиплекса необходимо задать параметры модуляции, способ упаковки данных логических каналов мультиплекса и схему мультиплекса.
5.2 Параметры модуляции:
• полоса радиоканала (100, 200 или 250 кГц);
• тип модуляции несущих канала КОС (QPSK, 16-QAM или 64-QAM);
• скорость помехоустойчивого кода канала КОС (1/2, 2/3 или 3/4);
• количество кадров временного перемежения;
• наличие канала НСК;
• наличие канала НКД.
5.3 Способ упаковки данных логических каналов мультиплекса РАВИС (см. пункт 4.3) должен выбираться исходя из количества передаваемых сервисов, требований к битовому потоку сервисов, требований приемного оборудования и пр.
5.4 Схема мультиплекса должна включать перечисление сервисов, входящих в каналы КОС, НСК, НКД. Для каждого сервиса, если он не поступает в формирователь контента РАВИС уже готовым к передаче, должен быть указан список элементарных потоков, из которых он состоит, а для каждого такого элементарного потока должна быть указана информация об источнике данных элементарного потока.
5.5 Скорости битовых потоков данных логических каналов не должны превышать значений:
• для канала КОС - в соответствии с таблицей 1;
• для канала НСК - 11 408,6 бит/с;
• для канала НКД - 4 548,0 бит/с.
5
Необходимо учитывать, что битовый поток каждого логического канала состоит из заголовков КД РАВИС, полезной нагрузки (данных элементарных потоков) и системных данных (описаний элементарных потоков и описаний сервисов), поэтому битовый поток каждого логического канала на выходе формирователя контента превышает суммарный битовый поток всех входящих в его состав элементарных потоков.
Таблица 1 - Пропускная способность канала КОС в разных режимах (в бит/с) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Формирователь контента должен формировать выходной поток данных, содержащий полученные на входе данные готовых сервисов и элементарных потоков, организованных в сервисы, упакованные в логические каналы мультиплекса РАВИС в соответствии с заданными параметрами. Выходной поток формирователя контента должен соответствовать формату входных данных модулятора системы РАВИС.
6.2.1 Вход формирователя контента должен иметь интерфейс Ethernet 10/100/1000 Base-T. Сетевое соединение Ethernet должно использоваться для передачи IP-пакетов. IP-пакеты должны содержать данные готовых сервисов и/или данные элементарных потоков, организующихся затем в сервисы. Упаковка должна осуществляться в соответствии с протоколом DCP ГОСТ Р 54708-2011. Правила формирования TAG-пакета для входа формирователя контента приведены в приложении В.
Дополнительно допускается использование иных интерфейсов (ASI, USB и пр.).
6.2.2 Выход формирователя контента должен иметь интерфейс Ethernet 10/100/1000 Base-Т. Сетевое соединение Ethernet должно использоваться для передачи IP-пакетов. IP-пакеты должны содержать кадры данных логических каналов КОС, ИСК, НКД и параметры, передаваемые на несущих ППС, в соответствии с ГОСТ Р 54309-2011. Упаковка кадров данных логических каналов и параметров передачи должна осуществляться в соответствии с протоколом DCP ГОСТ Р 54708-2011.
6.2.3 Формирователь контента должен иметь интерфейс дистанционного управления и мониторинга Ethernet 10/100/1000 Base-T. Управление должно осуществляться в соответствии с протоколом DCP ГОСТ Р 54708-2011.
6.3.1 При эксплуатации, хранении, транспортировке и испытаниях оборудование формирователя контента должно соответствовать требованиям безопасности и санитарии по ГОСТ 12.1.030-81, ГОСТ Р МЭК 60065-2005 и ГОСТ 12.2.007.0-75.
6.3.2 В оборудовании формирователя контента должна быть исключена возможность воспламенения при случайном замыкании в цепях питания и при неправильном включении полярности электропитания.
6.3.3 Температура наружных поверхностей оборудования формирователя контента во
время работы при нормальных климатических условиях по
ГОСТ 15150-69 не должна превышать плюс 45 °С в местах постоянного контакта оператора с поверхностью и плюс 60 °С в местах случайного прикосновения к поверхности.
6.3.4 В оборудовании формирователя контента должна быть исключена возможность прикосновения персонала к точкам с напряжением более 36 В.
6.3.5 Электрическая прочность изоляции между элементом заземления и каждым из потенциальных полюсов ввода электропитания должна выдерживать без пробоя испытательное напряжение постоянного тока 1410 В.
6.3.6 Сопротивление изоляции между элементом заземления и каждым из потенциальных полюсов ввода электропитания должно быть не менее 2 МОм.
6.3.7 В оборудовании формирователя контента должно быть обеспечено электрическое соединение всех доступных прикосновению металлических нетоконесущих частей, которые могут оказаться под напряжением, с элементами заземления.
Значение сопротивления между элементом заземления и каждой доступной прикосновению металлической нетоковедущей частью оборудования формирователя контента, которая может оказаться под напряжением, не должно превышать 0,1 Ом.
6.4.1 Электропитание формирователя контента должно осуществляться от одного из следующих источников питания:
1) от сети переменного тока с номинальными значениями напряжения 220 В и частоты 50 Гц. В этом случае требования к электропитанию должны соответствовать приложению 2 Правил [3];
7